What are non-user stories?

Not all stories can be written from user-perspective and trying to write it in the user-story format is an inefficient use of PM time and scrum team member’s time. These are non-functional requirements otherwise called as non-user stories.

So, let’s first define non-user stories:
Business-driven and system-level requirements that don’t fit user-story format, and need to be implemented to:

• Increase customer satisfaction
• Meet non-negotiable business requirements
• Enable company and product to track goals and conduct experiments

These business and system-level requirements are co-created by Product and engineering. In some instances, both PM and engineering lead for the project might have to collaborate with stakeholders (internal and external) depending upon the type of requirements to understand the requirement fully to determine how to support it.

1. Performance :

Response time refers to the time taken by the product to respond to user's request. Performance is measured primarily by response time and throughput. It determines how fast or slow the product responds when the user interacts with it ( could be an input of information, zooming in to view a picture, scrolling down a feed). Think of Response time as the limit up to which users accept up to a certain amount of delay (ie. latency).

In your discussions with the engineering team, this can be defined on a screen basis. For e.g, the landing page of the e-commerce website, the catalog pages, and an item's detail page might have a response time that is different from the page where order history is displayed
*_ Latency_ is determined by the resources used to provide the response. The second parameter is the number of requests or transactions that your product can handle at any point in time. This could be a simple number of user requests per minute. Both the information combined will be useful to QA as well to conduct load testing to ensure the product doesn't break or become unresponsive during peak times